Skip to content

Fix #1528: add macro expansion for @rx operator #1536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

asterite3
Copy link

@asterite3 asterite3 commented Aug 19, 2017

There is a problem that macro expansion in regex of @rx operator does not work (see #1528).

This pull request adds a code that tries macro expansion on regex before matching, and, if regex text changed after expansion, create new Regex object from it and use that for matching.

Also, add an optimization: in Rx constructor, check if macro expansion is possible at all for regex (%{...} present in it), cache the result of this check (save it in a boolean field of Rx object) and try macro expansion before matching only if check was positive. This should avoid macro expansion attempts + string compares for most regexes (at least, for most regexes in OWASP CRS).

Also, add a regression test.

Fixes #1528

try to use macro expansion on @rx argument before matching.
If after expansion argument changed, make new Regex from
the macro-expanded argument and use that for matching.
Fixes owasp-modsecurity#1528
Added method checkIfMacroExpansionPossible() called by Rx
constructor to check if "%{...}" construct is present in regex.
If not, Rx::evaluate should not try macro expansion on regex
before matching.
@victorhora
Copy link
Contributor

PR looks great. Will also fix #1552.

Ready to merge once @zimmerle confirms it's all good with his buildbots :)

@defanator
Copy link
Contributor

Hey @zimmerle @victorhora - any reasons this PR is still not merged?

Just wondering due to related issue reported here:
#1552

Thanks!

@zimmerle
Copy link
Contributor

zimmerle commented Oct 4, 2017

Hi @defanator,

It is in my queue to review. In particular I am interested to understand if there is memory corruption in
a thread environment. It seems to be safe to use in multi-process.

@zimmerle zimmerle self-assigned this Oct 4, 2017
zimmerle pushed a commit that referenced this pull request Oct 6, 2017
zimmerle pushed a commit that referenced this pull request Oct 6, 2017
@zimmerle
Copy link
Contributor

zimmerle commented Oct 6, 2017

Hi @asterite3,

Thank you for the patch! It is already merge. Notice however that I have removed the optimization, as it demands further investigation.

@zimmerle zimmerle closed this Oct 6, 2017
@zimmerle zimmerle self-requested a review October 6, 2017 21:43
zimmerle pushed a commit that referenced this pull request Dec 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants